Closed
Bug 326732
Opened 19 years ago
Closed 18 years ago
disabled submit inputs have text selection (I-beam) cursor
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: aguertin+bugzilla, Unassigned)
References
()
Details
(Keywords: regression, testcase)
Disabled submit inputs have the text cursor instead of an arrow like non-disabled ones. Testcase in URL. Does not occur on FF1.5 Windows, so I'm assuming it's a regression, though it could conceivably be Linux only...
Comment 1•19 years ago
|
||
No, I can see it too on windows, with current trunk build. Might be useful to know when this regressed.
Comment 2•19 years ago
|
||
Regression between 1.9a1_2006012517 and 1.9a1_2006012609.
Comment 3•19 years ago
|
||
Ah, thanks Ria. So I guess bug 317375 is responsible for the change in behavior. But it seems to me this behavior is a logical consequence, considering the cursor: inherit; rules in forms.css for disabled inputs. This was added with bug 260399. Boris you insisted on changing it from "default" in the CSS to "inherit". Are you sure it shouldn't be "default"?
Blocks: 317375
Comment 4•19 years ago
|
||
> But it seems to me this behavior is a logical consequence, considering the > cursor: inherit; rules in forms.css for disabled inputs. Why? It seems to me the behavior is a logical consequence of roc changing (well, actually removing) the hit-testing going on in nsHTMLButtonControlFrame in bug 317375. > Are you sure it shouldn't be "default"? Yes, since "cursor" is inherited. Consider: <div style="cursor: pointer"><input disabled></div> Imo the cursor should be a pointer (which is what it would be if input were not special), not an arrow (which is what it would be if we use "default"). In any case, the inherit is not the problem. The problem that the text frame is ending up as the target when we're doing UpdateCursor is. That didn't use to be the case. That said, the old hit testing in nsHTMLButtonControlFrame is a little odd for <button>. Perhaps nsGfxButtonControlFrame should override some of this stuff? After all, an <a> inside a <button> should be clickable, and I'm not sure it was before...
Flags: blocking1.9a1?
Comment 5•19 years ago
|
||
Yeah, you're right. I guess this bug and bug 326827 could be related to each other.
OS: Linux → All
Should be fixed by the patch in bug 326827.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Updated•18 years ago
|
Flags: blocking1.9a1?
You need to log in
before you can comment on or make changes to this bug.
Description
•